As the server design had been set quite rigidly, implementing the required architecture was simply a matter of following this design. Despite this, the server implementation is by no means perfect; there are a number of potential issues that have arisen while attempting to stick to the design, mainly with the parts that deal with threading and synchronisation. This section shall discuss these issues, as well as giving general information about the implementation and the problems that had to be solved.

The entirety of the server was coded in Java, similarly to the client. Java was chosen as it was the programming language that the majority of the team was most comfortable with. Additionally, the standard library that Java provides contains pre-made thread-safe data structures and utilities (e.g, for dealing with network sockets and file management) which helped speed up server implementation significantly. As Java is widely used, searching the web for any Java-specific problems that came up during the implementation usually returned a large number of results along with solutions for those problems.

\subsection{Threading \& Synchronisation}

Each connection creates a new thread running a client controller for that particular connection -- as required by the design -- allowing all connections can be handled simultaneously. This meant that the server and client models had to be implemented in a thread-safe manner in order to prevent interleaving, as multiple threads may potentially attempt to modify these models at the same time. Fortunately, Java provides built-in thread-safe data structures through its concurrency package such as linked lists and hash maps, as well as the synchronised language construct which can be applied to class methods. This language construct attempts to lock the intrinsic lock of that particular class instance before proceeding through the method, unlocking it once it returns. Any other thread that calls this method blocks until the lock is unlocked. This means that no interleaving can occur for these methods and thus meant that making our data structures thread-safe was a simple process.

\subsection{External Libraries}

Most of the required server functionality was implemented using only the built-in Java libraries and our own internal components. However, we did have to rely on some external libraries for the avatar uploading and downloading functionality. 

A public domain Base64 encoder and decoder\footnote[5]{\url{http://iharder.sourceforge.net/current/java/base64/} \indent\newline(Accessed: March 2012)} was used to convert the received Base64 data back into its original format for storage, and vice versa for returning that data to the users. While not particularly necessary (the string could have simply been stored in the database as part of the user model), it meant that we could then easily check the type of that particular file to ensure that it is an image, and also helped in debugging to ensure that the file was being received properly. 

In addition to this, the IO component of the Apache Commons library\footnote[6]{\url{http://commons.apache.org/} \indent\newline(Accessed: March 2012)} was used to copy the image for permanent storage, as Java itself is lacking a utility to perform this sort of action -- we would have had to write our own method for doing this otherwise, which while easily done, seemed unnecessary when the Apache Commons library could already do this for us. On the other hand, including an entire library for one function is rather wasteful but still seemed like a good idea as it saved us some time.

As mentioned in design, the SQLite\footnote[7]{\url{http://sqlite.org/} \indent\newline(Accessed: March 2012)} library was used as the database backend. Along with this, the SqliteJDBC\footnote[8]{\url{http://www.zentus.com/sqlitejdbc/} \indent\newline(Accessed: March 2012)} Java JDBC driver was used.

\subsection{Issues}

As mentioned in the introduction, most of the issues with the server implementation are due to the way in which threading works. Firstly, as a new thread is created each time a new connection is made, this means that the number of threads running from the application could become quite excessive when there are many users connected. Most sane operating systems implement some sort of maximum thread count per application also, so this would become a limiting factor for the number of users the server can support. Utilising a thread pool would have been a preferable solution, meaning that we would have a fixed number of threads which would then rotate through each connection in a round-robin fashion, checking if there is any messages to be read -- parsing it if so -- before continuing to the next awaiting connection. This would, however, have added some extra complexity to the server as we would need to implement a way of queueing connections that are to be read from but would have been a lot more efficient in the end.

The way in which messages parsing works means that only one message can be processed at a time from that particular client, even if they had sent several messages at once. For the sake of optimisation and in addition to the thread pool proposed above, another thread pool that deals with individual messages could be added. Each time a message is received from a client, the message could be added to the queue associated with this pool, which would then have a fixed number of threads operating on it like before. These threads would then perform the particular logic associated with that message. This would mean that multiple messages from the same client could in fact be handled simultaneously, at the cost of -- again -- significant added complexity.

In addition, as detailed in the design section, users are uniquely identified by their e-mail address. This means that this information cannot be changed easily: contact lists are stored as arrays of e-mail addresses, and therefore, if a user changed their e-mail address this change would have to be propagated across all contact lists which that user is on. This is extremely inefficient. Users should be switched to be being referenced a unique numeric identifier, independent of their e-mail address.
